1. Technical Field of the Invention
This invention pertains to control and management of communication traffic. More specifically, it relates to the use of filtering in the control and management of communication traffic.
2. Background Art
Referring to FIG. 1 in connection with FIG. 2, in a network system including two nodes 30, 32 connected by, for example, the Internet 40, the nodes are typically connected through router 35, 37 firewalls 36, 38, respectively. The case is commonly encountered where traffic between nodes 30, 32 is to be restricted based on something other than data in the packet 140. For most business, not all applications are created equal: some data deal with sensitive matters, and usage is restricted to groups or individuals. There is, in this instance, a need to restrict certain types of traffic by group or application, and the data required to do so is typically not available in packet 140.
Internet protocol (IP) packet filtering, in the context of the TCP/IP protocol suite, is the base technology commonly implemented in firewalls 36, 38 and related systems. It is important for network integrity and security. Virtual private network (VPN) technology based on the Internet protocol security (IPsec) protocols also utilizes packet filtering. VPNs are an important enabler for e-business, both for consumer-to-business (C2B) and business-to-business (B2B) activity.
C2B and B2B applications of VPN technology today must rely on attributes actually contained within the IP packets 140 for their security, or be handled at the application level. This is because IP packet filtering is done based on data actually contained within the datagram 140, either the IP header 142, ULP headers 144, or possibly, the payload portion 154 of the packet.
Since packet filtering does not provide the necessary capabilities, if additional control and management of aspects of communication traffic are necessary, three techniques are used: (1) application level control, (2) proxy server control, or (3) add packet data control. According to (1), controls are built into the application, such as server application 42. In this case, server application 42 includes configuration capability to control its traffic based on user ID or profile. For example, individual applications 42 may have their own user authorization lists or exit programs allowing control over what users may do. This approach is not centralized and is not standard. Each application may do control differently, and each application must be configured. According to (2), a proxy server 34 controls applications that go into a node 30 from node 32. An application or set of applications or servers is be ‘front-ended’ by a proxy server 34 which intercepts traffic for its configured applications and performs checking on what users may access. Proxy server 34 creates what looks like node 30, to node 32, but passes through to node 30 only authorized traffic, other traffic being blocked or discarded with, perhaps, an error message. This technique centralizes things somewhat, but has performance problems because traffic comes in from router 35 and up through the stack to an application layer, the proxy 34 has to pretend that it is an application, and then send data back down the stack, and the real server 30 must do the same. Both techniques (1) and (2) address the problem of data required for control logic in the application not existing in the datagram (aka packet), so the control decision is moved up in the application layer where the required data normally resides. The application layer typically knows the user ID which is requesting data. According to (3), additional required data 152 is added in the packet 140, and this allows filter rules to be written. Thus, application level information 152 may be added to a variety of IP packets 140, so that these decisions can be made about the traffic. However, this makes the packets non-standard, in the sense that these special headers require special function associated with the stack.
The above control and management techniques have various deficiencies, including lack of centralized control when spread over multiple applications and servers, increased overhead when the entire protocol stack must be traversed by IP packet traffic in the case of application control 42 or proxy servers 34, lack of consistency when applying control files, authorization lists, etc. for different applications or servers from different vendors, and lack of security.
It is an object of the invention to provide an improved system and method for control and management of aspects of communication traffic.
It is a further object of the invention to provide a system and method for control and management of aspects of communication traffic within filtering.
It is a further object of the invention to provide a system and method for centralizing communication management and control within filter rules.
It is a further object of the invention to provide a system and method having reduced overhead for controlling and managing communication traffic, without requiring that IP packet traffic traverse the entire protocol stack to be disallowed.
It is a further object of the invention to provide a system and method having improved consistency, with all the rules for access expressed in the same way.
It is a further object of the invention to provide a system and method for managing and controlling communication traffic having improved security through visibility and coherence by centralizing the access rules and centralizing associated logging.